<html>

<head>
<title>Command Pattern</title>
<link rel="stylesheet" type="text/css" href="../../../style.css">
</head>

<body>

<h1>Command </h1>
<ul>
  <li><a href="#Purpose">Purpose</a></li>
  <li><a href="#Structure">Structure</a></li>
  <li><a href="#Interaction">Interaction</a></li>
  <li><a href="#Applications">Applications</a></li>
  <li><a href="#Consequences">Consequences</a></li>
</ul>
<h2><a name="Purpose">Purpose</a></h2>
<ul type="square">
  <li>Encapsulate a request as an object, thereby letting you parameterize 
	clients with different requests, queue or log requests, and support undoable 
	operations.</li>
</ul>
<h2><a name="Structure">Structure</a></h2>
<p>&nbsp; <img border="0" src="Command_Model1.gif" width="600" height="209"></p>
<ul type="square">
  <li><b>Command : declares an interface for executing an operation.</b></li>
  <li><b>ConcreteCommand :</b> defines a binding between a Receiver object and 
	an action. implements Execute by invoking the corresponding operation(s) on 
	Receiver.</li>
  <li><b>Client :</b> creates a ConcreteCommand object and sets its receiver.</li>
  <li><b>Invoker :</b> asks the command to carry out the request.</li>
  <li><b>Receiver :</b> knows how to perform the operations associated with 
	carrying out a request. Any class may serve as a Receiver.</li>
</ul>
<h2><a name="Interaction">Interaction</a></h2>
<p><img border="0" src="Command_Seq1.gif" width="509" height="292"></p>
<ul type="square">
  <li>The client creates a ConcreteCommand object and specifies its receiver.</li>
  <li>An Invoker object stores the ConcreteCommand object.</li>
  <li>The invoker issues a request by calling Execute on the command. When 
	commands are undoable, ConcreteCommand stores state for undoing the command 
	prior to invoking Execute.</li>
  <li>The ConcreteCommand object invokes operations on its receiver to carry out 
	the request.</li>
</ul>
<h2><a name="Applications">Applications</a></h2>
<ul type="square">
  <li>parameterize objects by an action to perform, as MenuItem objects did 
	above. You can express such parameterization in a procedural language with a 
	callback function, that is, a function that's registered somewhere to be 
	called at a later point. Commands are an object-oriented replacement for 
	callbacks.</li>
  <li>specify, queue, and execute requests at different times. A Command object 
	can have a lifetime independent of the original request. If the receiver of 
	a request can be represented in an address space-independent way, then you 
	can transfer a command object for the request to a different process and 
	fulfill the request there.</li>
  <li>support undo. The Command's Execute operation can store state for 
	reversing its effects in the command itself. The Command interface must have 
	an added Unexecute operation that reverses the effects of a previous call to 
	Execute. Executed commands are stored in a history list. Unlimited-level 
	undo and redo is achieved by traversing this list backwards and forwards 
	calling Unexecute and Execute, respectively.</li>
	<li>support logging changes so that they can be reapplied in case of a 
	system crash. By augmenting the Command interface with load and store 
	operations, you can keep a persistent log of changes. Recovering from a 
	crash involves reloading logged commands from disk and reexecuting them with 
	the Execute operation.</li>
</ul>
<h2><a name="Consequences">Consequences</a></h2>
<ul type="square">
  <li>Command decouples the object that invokes the operation from the one that 
	knows how to perform it.</li>
  <li>Commands are first-class objects. They can be manipulated and extended 
	like any other object.</li>
  <li>You can assemble commands into a composite command. An example is the 
	MacroCommand class described earlier. </li>
  <li>It's easy to add new Commands, because you don't have to change existing 
	classes.</li>
</ul>

</body>

</html>
